In the field of information modeling and model-based application development, it may be useful to utilize structural commonality of objects in an application domain. This may be supported by a modeling language, for example, using structure or record types that include typed data members. Record types may be defined through a process of inheritance and refinement from an existing record type, where a derived record inherits all data members of the parent record and may further add new data members or refine the types of the inherited data members.
For example, in modeling a processor, instructions may be associated, among other attributes, with attributes that indicate resources that the instructions may access, e.g., data resources such as registers or memory. Those resources may be represented, for example, using record types, e.g., a “Resources” record type and/or refinements of that type. For example, a Load instruction may be modeled using the following code, denoted Code 1:
Code 1meta type Resource: record { ... };// defines the Resourcemeta-typemeta type Register: record Resource { ... };// inherits from Resourcemeta type Memory: record Resource { ... };// inherits from Resourcemeta type Instruction: record {  resources: record { };// defines “resources” to be(empty) record type};type Load: record Instruction {// inherits from Instruction  resources: {// refines the inherited attribute “resources” to contain Load-specific resources   target_register: Register;   source_memory: Memory;   base_register: Register;  };};type LoadIndex: record Load {// inherits properties from Load  resources: {// refines the inherited attribute “resources” to contain LoadIndex-specific resources   index_register: Register;  };};
In Code 1, the “meta” keyword may be used to specify that the type defined is part of the meta-model. A conceptual model and/or a meta-model may provide a lexicon for a model-based application, including generic concepts, intended semantics, and other information regarding the structures and types used by the modeling language. For example, the meta-model for a processor may include the general notion of an instruction, e.g., the Instruction type of Code 1, since “instruction” is a concept common to all processors, whereas a specific instruction, e.g., the Load type of Code 1, may be specific to a given processor design and may therefore part of the model, but not the meta-model.
Unfortunately, if Code 1 is used, then a modeler may need to manually enforce any integrity constraint, for example, requiring that all subcomponents (e.g., target_register in the Load record) be of the “Resource” type. This may be error-prone, and may also affect model-based applications which access or operate on information contained in the model (e.g., the Load instruction) based only on their knowledge of the meta-model (e.g., Instruction, and not Load). For example, an application may determine, based on the meta-model, that all instructions (including Load instructions, which inherit from the Instruction meta-type) have resources, so it may be necessary for the modeler to ensure this constraint, i.e., that the Load instruction actually contains resources of the correct type.
Alternatively, some modeling languages may utilize maps to enforce types, for example, as demonstrated in the following code, denoted Code 2:
Code 2meta type Instruction: record {  resources: map<string, Resource>// defines “resources” to be a map type between strings and Resources};type Load: record Instruction { };// inherits from Instruction
In Code 2, the “resources” data member is defined as a map between strings and Resources, and thus any specific instance of the resources map may only include resources with values of the “Resource” type. Unfortunately, if Code 2 is used, it may still be required to restrict the resources map in the Load type to contain only the Load-related resources. Furthermore, to capture the intended modeling semantics, it may be necessary to associate specific resources (map keys) with specific Resource values, e.g., by instantiating the map. Accordingly, instead of utilizing a universal map from strings to resources, a specific map may be defined, for example, as demonstrated in the following code, denoted Code 3:
Code 3type Load: record Instruction {     // inherits from Instructionresources: map<      // refines the inherited attribute “resources”    <“target_register”, GeneralPurposeRegister>,    <“source_memory”, MainMemory>,    <”base_register”, GeneralPurposeRegister>  >};
In Code 3, the GeneralPurposeRegister and MainMemory types may be previously defined instances of the Register and Memory types, respectively. Unfortunately, utilization of a specific map as in Code 3 may represent the Load instruction as a particular instance of a load instruction rather than as a general Load type in the model, and thus may not allow for further refinement at the type level. For example, adding new entries into the map, e.g., a <“index_register”, Register> entry for defining a “LoadIndex” instruction, violates the principles of refinement. Furthermore, the resources map in the Load instruction of Code 3 may only restrict an instance of the Load type to have a subset of the specified entries, but may not enforce all of the entries (e.g., an instance of the Load instruction type of Code 3 may have a target register and a base register, but no source memory), which violates the intended semantics.
The foregoing examples of the related art and limitations related therewith are intended to be illustrative and not exclusive. Other limitations of the related art will become apparent to those of skill in the art upon a reading of the specification and a study of the figures.